1. Field of the Invention
The present invention relates to a transaction processing system and a transaction processing method in which a plurality of transactions make accesses to the same file in parallel.
2. Description of the Background Art
In general, in the transaction processing system, the execution of processing is managed in units of a flow of processing called transaction. For example, a necessary processing is executed and a processing result is returned in response to a processing request received from a terminal device or a network. Such a flow for executing a processing that is activated somehow will be referred to as a transaction.
The individual transaction makes updates of data to be recorded and managed by one or a plurality of files (or databases) in a process of its execution. The transaction processing system guarantees that such updates of one or a plurality of data are either atomically committed or aborted. Namely, the commit validates all the updates concurrently, whereas the abort discards all the updates and sets a state of the file back to the state before executing the transaction. In addition, the transaction system also guarantees that once the transaction is committed, the updates made by that transaction will never be cancelled.
There are various methods for realizing such a transaction processing system that are already well known, as can be found in J. Gray and A. Reuter: xe2x80x9cTransaction Processing: Concepts and Techniquesxe2x80x9d, Morgan Kaufmann Pulishers, Inc., for example.
A case that is difficult to handle in the transaction processing system is the case where a plurality of transactions make updates of data on one and the same file concurrently. No problem would arise if an update of one file is permitted only to one transaction at a time. However, in order to improve the performance by processing a plurality of transactions in parallel concurrently, it is necessary to enable updates of data to be recorded and managed at different portions of one and the same file concurrently. This problem also arises in the case of using databases rather than files. In the following, the case of using files will be described, but the case of using databases is similar.
In order to realize such a transaction processing system for carrying out the update processing in parallel, a scheme called WAL (Write Ahead Logging) has been widely used conventionally. In this scheme, when a plurality of transactions made updates with respect to a file read out to a buffer on a memory, the log file records which part of which file has been rewritten by which transaction and how it is rewritten. In addition, a timing is controlled such that the update made on the buffer will not be written back to the original file on a memory medium such as hard disk until it is guaranteed that the update information recorded in the log is written into a stable memory device (a hard disk, for example) so that it will not be lost,
In the WAL scheme, all the update histories are recorded in the log so that when a system fault occurs, the files can be recovered to their correct states by using the log. Namely, when the system is re-activated after a fault occurred, the transaction processing system refers to the log and correctly reflects an update made by the committed transaction that is still not reflected in the file. Also, if there is an update made by the aborted transaction that is already written into the file, a processing for cancelling that update will be carried out. By such a recovery processing, it is possible to guarantee the atomicity, durability, isolation and consistency of transactions even when a fault occurs.
In the transaction processing system according to the conventional WAL scheme, when the transaction updates a file, the update content is written into the log first and then the file itself is updated, so that a complicated processing procedure will be required in order to manage the file sharing by a plurality of transactions. Moreover, the writing processing is required twice for one update, once for the log and once for the file itself. In addition, a complicated processing procedure is also required for a recovery processing to recover a consistent state of the file by using the log. Furthermore, the recovery processing must be carried out completely at a time of re-activation after a fault occurrence, so that the re-activation requires a considerable amount of time.
Another scheme for realizing the transaction processing system is the shadow page scheme. In this scheme, in the case of updating a file, a page with a file before the update written therein and a page with a file after the update written therein are provided on the hard disk, and the file management data are switched atomically at a time of the commit of the transaction. For this reason, it is possible to guarantee that the correct file always exists on the hard disk.
In the shadow page scheme, the file in the correct state always exists on the hard disk so that there is an advantage that the overhead of the recovery processing at a time of a fault occurrence is small. However, the shadow page scheme employs a basic operation for atomically switching pages recording two files, one before the commit and another after the commit of one transaction, so that in the case where a plurality of transactions wish to update one and the same file, it is necessary to serialize these transactions and make updates sequentially. In order to enable updates of different portions of one and the same file by a plurality of transactions in parallel as in the WAL scheme, it is insufficient to use the shadow page scheme alone, and it is necessary to employ some devise such as the data management using the log similarly as in the WAL scheme. For this reason, even though the shadow page scheme can be implemented easily, it becomes necessary to implement a complicated data management in addition.
Next, a conventional file system will be briefly described. FIG. 43 shows an example of a conventional transaction processing system. In the conventional transaction processing system, application programs 101 for processing transactions carry out data operations through a database management system 102. A file system 103 carries out operations and management of files recorded in a stable memory device such as hard disks 104 The database management system 102 manages data required by the application programs 101 by using files management by the file system 103. The database management system 102 also carries out a concurrency control during operations with respect to data shared by a plurality of application programs 102.
It is therefore an object of the present invention to provide a transaction processing method and a transaction processing system capable of easily and efficiently realizing the file update processing by a plurality of transactions operating in parallel as well as the recovery processing at a time of a fault occurrence.
According to one aspect of the present invention there is provided a transaction processing method, comprising the steps of: executing a plurality of transactions that carry out update processing with respect to one file read out onto a buffer region; and writing said one file into a stable memory device at a time of commit of one transaction among the plurality of transactions, said one file containing a content of committed updates made by said one transaction and a content of non-committed updates made by other non-committed transactions, and information for cancelling the non-committed updates.
According to another aspect of the present invention there is provided a transaction processing system, comprising: a reading unit configured to read out one file that is to be a transaction processing target from a stable memory device onto a buffer region; an update unit configured to update said one file by writing a content of updates with respect to said one file made by each one of a plurality of transactions and information for cancelling the updates, into said one file on the buffer region; and a writing unit configured to write said one file into the stable memory device at a time of a commit of one transaction among said plurality of transactions, said one file containing a content of committed updates made by said one transaction and a content of non-committed updates made by other non-committed transactions, and information for cancelling the non-committed updates.
According to another aspect of the present invention there is provided a computer usable medium having computer readable program codes embodied therein for causing a computer to function as a transaction processing system, the computer readable program codes include: a first computer readable program code for causing said computer to read out one file that is to be a transaction processing target from a stable memory device onto a buffer region; a second computer readable program code for causing said computer to update said one file by writing a content of updates with respect to said one file made by each one of a plurality of transactions and information for cancelling the updates, into said one file on the buffer region; and a third computer readable program code for causing said computer to write said one file into the stable memory device at a time of a commit of one transaction among said plurality of transactions, said one file containing a content of committed updates made by said one transaction and a content of non-committed updates made by other non-committed transactions, and information for cancelling the non-committed updates.
Other features and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings.